Aspects of the present invention relate generally to integrated circuit designs, and in particular to techniques for simulation and test of such designs.
Hardware designers, for example integrated circuit (IC) designers, do not always design every component of a new hardware device. While designers may design one or more components of a particular device, they often employ component designs (also known as intellectual property, or IP) from one or more third-party IP providers. Using components from third-party IP providers can facilitate the design by avoiding the need for the designer to design every aspect of the device's functionality.
Hardware designers may employ a hardware based verification platform to perform certain operations on a design. Hardware verification platforms can enable testing of the various components of the design which facilitates design analysis and debugging. Multiple aspects of the hardware design typically may be tested. For example, a hardware design may undergo architectural simulation and analysis and debugging where the functionality of each of the components being implemented in the design is tested, for example, with transaction level modeling (TLM) or bus functional modeling. The hardware design may additionally undergo circuit simulation and analysis where the signals between components are tested, for example using register transition level (RTL) analysis. Other steps may include system simulation, for example to model the components of a system together, and system and software emulation, for example to model execution of software elements executing on a modeled system. Once a design is completed, one or more physical components of the device may be tested and verified.
A programming model can be used during verification and simulation and may be defined according to a specification for the IP component undergoing testing. A conventional programming model definition for a third party IP component includes a set of register accesses. The definition will include two types of accesses: a definition for the protocol related register accesses (e.g. reset), and a definition for design specific register accesses (e.g. power domain management).
Using this programming model, a software stack, such as firmware or a bare-metal driver, will be developed to manage IP component behaviors during testing. However, although the specification details may be utilized to verify certain accesses of the IP component, certain other actions of the IP component, such as design specific register accesses, cannot be generalized or abstracted, and therefore are not captured in a specification or protocol. Therefore, complete testing often requires a device specific driver.
Furthermore, during the conventional development of a programming model for a third party IP component, the programming model is defined and tested without specific knowledge of the target system-on-a-chip (SOC). When an IP component is integrated into an SOC, the IP component related programming model is consumed into the programming model for the SOC, on top of which the SOC software can then be developed and tested.
However, when developing SOC software that utilizes the IP component, and integrating the IP component into the associated SOC, the IP component related programming model and the defined requirements for the SOC may have gaps in functionality and control. Therefore, although the IP component programming model may have been individually tested and verified, it is also necessary to test and verify a corresponding programming model at the SOC level. This process consumes resources and time. Additionally, when testing the SOC software, changes to the design IP (DIP) definition may be needed, requiring the partial re-writing of the software stack and complete re-testing of the DIP programming model.
As a result, multiple modules and interfaces, as well as entirely new drivers, are often created to simulate a driver and interface associated with the IP component. However, driver development is error-prone and time consuming. Additionally, certain aspects of the testing cannot be completed until the IP component, and the system on a chip (SOC) on which the IP component is implemented, have been created.
Therefore, there is a need for a standardized programming model definition that can be used throughout the verification and testing process.